Read Only Registry entries
Two Registry entries allow all or part of the system to be read-only. The ReadOnly (System) Registry entry and ReadOnly (Table) Registry entry allow System Administrators to "turn off" record insertions and updates while still allowing the system to be operational.
Prior to
The system wide read-only entry ensures that data is not modified in any modules, including the
- Disabling data changes while the system is upgraded.
- Providing read-only access for certain users / groups.
- Allowing data loads to be checked before going live.
The table specific read-only entry allows individual tables or all tables to operate in a read-only state. If a table is read-only, data insertions and modifications are not permitted. The only exception is that changes to the
- Disabling data changes to a single table (as it may require maintenance).
- Providing read-only access to a table for certain users / groups.
- Allowing Registry based operations (e.g create a new sort) while the data is read-only.
The addition of the two ReadOnly Registry entries provides System Administrators with the ability to control access to data stored in
The ReadOnly Registry entries work alongside existing daInsert
permission to be able to create records. The ReadOnly entries do not override existing Registry entries to provide more privileges than would be the case if the entry was not set.
Specify that the entire system is read-only.
The system ReadOnly entry provides the following features:
- Data in all modules cannot be updated or created.
- Operations involving updates to tables are disabled, namely:
- Creating groups (uses egroups table).
- Manipulating the records in groups (uses egroups table).
- Creating batch exports (uses eschedule table).
- Running batch exports (uses eexports table).
- Create task templates (uses etemplates table).
- Change help contents (uses efieldhelp table).
- Operations that update the Registry are disabled, namely the creation, modification or deletion of any resources:
- List Settings
- Default Values
- Ditto Record
- Record Recall
- Record Template
- Reports
- Shortcut Settings
- Sorts
- Operations that update the Registry when performed, but only to record the entry selected, are not disabled, namely:
- List Settings
- Page View
- Query Default Values
- Reports
- Shortcut Settings
- Sorts
- Ad-hoc Sorts
The system ReadOnly entry may be used to limit access on a group or user basis.
Usage
This Registry entry can be assigned to users, groups and system-wide:
Key | User | Group | System |
---|---|---|---|
Key 1 | User
|
Group
|
System
|
Key 2 | user | group | Setting
|
Key 3 | Setting
|
ReadOnly
|
|
Key 4 | ReadOnly
|
||
Value | boolean |
User
|
user | Setting
|
ReadOnly
|
boolean |
Group
|
group | Setting
|
ReadOnly
|
boolean |
System
|
Setting
|
ReadOnly
|
boolean |
where:
boolean |
is either |
Examples
If users in group Test should not update any data, the following entry may be used:
Key | Setting |
---|---|
Key 1 | Group
|
Key 2 | Test
|
Key 3 | Setting
|
Key 4 | ReadOnly
|
Value | true
|
Entries may also be used in combination to achieve the desired effect. For example, if all users except those in group Admin should have read-only access, the following entries may be used:
Key | Setting |
---|---|
Key 1 | System
|
Key 2 | Setting
|
Key 3 | ReadOnly
|
Value | true
|
Key | Setting |
---|---|
Key 1 | Group
|
Key 2 | Admin
|
Key 3 | Setting
|
Key 4 | ReadOnly
|
Value | false
|
Specify that one or more (database) tables are read-only.
Usage
Key | User | User | Group | Group | Group | Group |
---|---|---|---|---|---|---|
Key 1 | User
|
User
|
Group
|
Group
|
Group
|
Group
|
Key 2 | user | user | group | group | Default
|
Default
|
Key 3 | Table
|
Table
|
Table
|
Table
|
Table
|
Table
|
Key 4 | table | Default
|
table | Default
|
table | Default
|
Key 5 | ReadOnly
|
|||||
Value | boolean |
User
|
user | Table
|
table | ReadOnly
|
boolean |
User
|
user | Table
|
Default
|
ReadOnly
|
boolean |
Group
|
group | Table
|
table | ReadOnly
|
boolean |
Group
|
group | Table
|
Default
|
ReadOnly
|
boolean |
Group
|
Default
|
Table
|
table | ReadOnly
|
boolean |
Group
|
Default
|
Table
|
Default
|
ReadOnly
|
boolean |
where:
boolean |
is |
The one exception to the rule is the Registry table (eregistry). If the Registry is made read-only, only explicit changes, that is changes made from the Registry module, are disabled. All implicit changes (e.g. adding a new sort definition) are still permitted. Hence the creation, modification or deletion of any resources is permitted, namely:
- List Settings
- Default Values
- Ditto Record
- Record Recall
- Record Template
- Reports
- Shortcut Settings
- Sorts
Using the first form of the table ReadOnly Registry entry:
Group
|
Default
|
Table
|
Default
|
ReadOnly
|
true
|
disables data creation and updates in all tables while still permitting most operational commands (e.g. report creation). When compared with the system ReadOnly setting, the table setting restricts only data modifications, rather than data and operational functionality.
User / group based variants of the table Registry entry may be used to restrict access to a select number of individuals. For example, if users in group
Group
|
Student
|
Table
|
ecatalogue
|
ReadOnly
|
true
|
As with the system ReadOnly entry, table based entries may be combined to produce the desired effect. For example, if users in group
Group
|
Student
|
Table
|
Default
|
ReadOnly
|
true
|
Group
|
Student
|
Table
|
egroups
|
ReadOnly
|
false
|
Group
|
Student
|
Table
|
eschedule
|
ReadOnly
|
false
|
Group
|
Student
|
Table
|
eexports
|
ReadOnly
|
false
|
Example 1
Your
System
|
Setting
|
ReadOnly
|
true
|
This setting will disable all
Example 2
You have received an initial data load in
Group
|
Default
|
Table
|
Default
|
ReadOnly
|
true
|
Group
|
Default
|
Table
|
egroups
|
ReadOnly
|
false
|
The disabling of the read-only status on egroups allows users to create and manipulate groups.
Example 3
You have created a duplicate version of your live system for access via the web. You do not want users to be able to alter any data in the web copy, however all other functionality should be available. The following Registry entries may be used:
Group
|
Default
|
Table
|
Default
|
ReadOnly
|
true
|
Group
|
Default
|
Table
|
egroups
|
ReadOnly
|
false
|
Group
|
Default
|
Table
|
eschedule
|
ReadOnly
|
false
|
Group
|
Default
|
Table
|
eexports
|
ReadOnly
|
false
|
Group
|
Default
|
Table
|
etemplates
|
ReadOnly
|
false
|
Group
|
Default
|
Table
|
efieldhelp
|
ReadOnly
|
false
|
The enabling of read / write access to the egroups, eschedule, eexports, etemplates and efieldhelp tables will allow full command functionality on a read-only system. You may want to exclude some of these tables if you want to further limit functionality. For example, removing efieldhelp will disable the updating of field level help.
Example 4
You are undertaking a clean up of the Lookup List table (eluts) so you would like to limit the update of Lookup Lists to users in group Admin. The following Registry entries may be used:
Group
|
Default
|
Table
|
eluts
|
ReadOnly
|
true
|
Group
|
Admin
|
Table
|
eluts
|
ReadOnly
|
false
|
When the eluts table is read-only, users may not insert new values into the table. This means all lookup lists are treated as read-only. Users may find this annoying as it may make it difficult to save records.
Example 5
You have just received an allocation of staff to add field level help for all modules in the system. You do not want the staff to alter any other data apart from field level help. You have created a group called Volunteers and placed the allocated staff in the group. The following Registry entries may be used:
Group
|
Volunteers | Table
|
Default
|
ReadOnly
|
true
|
Group
|
Volunteers | Table
|
efieldhelp
|
ReadOnly
|
false
|
In order for the volunteers to be able to create the field level help for all modules, you would also need to assign the daEditHelp
permission for group Volunteers.
In general, it is not wise to mix System based and Table based ReadOnly Registry entries. Consider the following settings:
Group
|
QA
|
Setting
|
ReadOnly
|
true
|
Group
|
QA
|
Table
|
eparties
|
ReadOnly
|
false
|
Which entry takes precedence? Can users in group QA write to the eparties table? The current implementation gives priority to the system entries over table based entries. So for the example above, users in group QA would not be able to write to the Parties module.